1. Field of the Invention
This invention relates to electronic mail. More specifically, the invention relates to reducing bandwidth used while conveying electronic mail messages.
2. Description of the Background Art
Electronic mail, commonly known as “email,” is a set of mechanisms designed to allow computer users to send messages (constituting “email messages,” “mail messages,” or more concisely just “messages”) to one another. Hereinafter, throughout the present specification, the term “message” means “email message”, unless specifically noted.
It is known in the art that email includes Internet email, but it is not limited thereto. There may be other types of email used, such as proprietary email systems, LAN-based email packages, mainframe systems, and the X.400 set of messaging standards (officially named ISO/IEC 10021) basically developed by ISO (International Organization for Standardization) and ITU (International Telecommunications Union).
The primary element of email is the message. It is known that every message consists of a header and a body, wherein the header contains various pieces of information about the message (such as “from,” “to,” “subject,” “date,” etc.) and the body contains the information that the sender wants to communicate. However, the header and body are non-limiting constituents of a message. Sometimes a message is described also as consisting of an envelope, wherein the envelope can specify the source (sender) and destination (recipient) of the message.
The message body basically includes free-form text data, i.e., plain text. However, while the usage of email has grown as a communication medium, people eventually wanted to send data other than plain text, such as attached files, multimedia content, formatting, etc.
A message is transmitted and routed by the aid of several tasks. Mail Transport Agents (MTAs) are responsible for routing messages. MTAs receive messages from various sources and decide where and how each message should be routed. Once an MTA has received a message, processed it, and decided where to route it, it conveys the message to a Mail Delivery Agent (MDA), which is responsible for delivering the message to another location, e.g., another MTA, a user's inbox, or a program that performs a special task.
While MTAs and MDAs are responsible for routing and transporting email messages, Mail User Agents (MUAs) are responsible for providing an interface for users to manage their mails, including viewing messages, managing mail folders, composing new mail messages, sending messages, replying to messages, forwarding messages, etc. In the early days of email the MUA typically resided on the same machine where a user received his email messages. Later on, two protocols, POP (Post Office Protocol) and IMAP (Internet Message Access Protocol), were created, thus allowing use of an MUA to read email that resides on remote machines. POP provides a protocol for MUAs to download the user's inbox from a remote mail server. IMAP provides a protocol for MUAs to manipulate mail folders on a remote mail server.
The operation of email is defined in standards. The standards are defined in a set of RCFs (Request For Comments), which define the various protocols and formats necessary to make email work across the Internet. For example, RFC822 (Standard for the Format of ARPA Internet Text Messages), published in 1982, is a Standard defining Internet email messages. RFC822 defines how email messages need to be formatted when being transmitted from host to host, thus providing a normalized format for email messages, so that different types of networks can transfer email from one to another. RFC822 does not define the format of stored email. For example, RFC822 describes that a message consists of header fields and, optionally, a body. The body is simply a sequence of lines containing ASCII characters. It is separated from the header by a null line (i.e., a line with nothing preceding the CR, Carriage Return character, followed by an LF, Line Feed character). Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. Standard RFC822 header fields include, for example, “From,” “Sender,” Reply-To,” “To,” “Cc,” “Bcc,” “Message-ID,” “In-Reply-To,” “References,” “Date,” “Received,” “Return-Path,” “Subject,” “Comments,” etc.
RCF1123 (Requirements for Internet Hosts—Application and Support), published in 1989, is another standard. It incorporates, amends, corrects, and supplements the primary protocol standards documents relating to hosts. Specifically, chapter 5 thereof is directed to email and RFC822.
It is noted that pure RFC822 message bodies are merely a series of text lines, which have no additional structure or meaning imposed on them. Because additional structure is sometimes desirable (including additional information such as attachments), several other conventions and standards have evolved over the years, outside the scope of the message format standard. For example, because the RFC822 message is limited to US-ASCII, pure RFC822 messages were limited thereby and could not include other characters used in non-English languages. Someone named André, for example, is not able to spell his name correctly in a pure RFC822 email message. In addition, RFC822 has no way to identify the structure of the data in stored in the message body. If a sender sends a message containing, for example, an HTML (HyperText Markup Language) file, it is up to the recipient to notice that the data can be viewed by an HTML browser. It is appreciated that if the format of the data had been identified in the message, the MUA could have taken steps necessary to present the data in a proper way. Furthermore, because RFC822 messages are text-based, MUAs need a way to identify non-text data (such as binary data) in order to handle it properly. MIME provides a way to deal with these limitations.
RFC2045 (MIME Part One: Format of Internet Message Bodies), RFC2046 (MIME Part Two: Media Types), RFC2047 (MIME Part Three: Message Header Extensions for Non-ASCII Text), and RFC 2049 (MIME Part Five: Conformance Criteria and Examples), all published in 1996, as well as RFC4288 (Media Type Specifications and Registration Procedures) and RFC4289 (MIME Part Four: Registration Procedures), both published in 2005, provide definition of the basic MIME standard.
The term “entity” or “MIME entity” refers to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. That is, an entity consists of the body of a message and the MIME-specific fields in the message header. The entity header contains fields used to describe the contents of the body, such as the type of data included in the body and the coded character set used in the data. MIME-specific header fields are generated by a sending MUA when a message is composed. A receiving MUA uses the MIME-specific header fields to decide how to extract any entities contained in a message.
The capacity of email communication has being growing over the years. This has affected communication network performance, as well as the performance of computers, e.g., computers where mail servers operate, where email messages are composed, and/or where email messages are received. Hence, efforts have been made to improve performance. For example, JP 2005-284955 (“Electronic Mail Transmitting/Receiving System”, Fujioka Hideki, published October 2005) acknowledges the necessity to preserve CPU resources by preventing unnecessary mail transmittance. Hence, a mail transmitting server to which transmission of electronic mail is requested, temporarily stores text of the electronic mail in an external storage device and transmits only a mail ID, a sender, and a title of the case for identifying the mail. A mail recipient makes a request to receive the text of the mail from the mail transmitting server only for those electronic mail messages whose text he desires to read by himself. The mail receiving server acquires the text of the mail from the mail transmitting server in response to the request and sends the text to the mail recipient. Thus, the text of electronic mail is prevented from being unnecessarily transferred via a network.
WO 0178334 (“Methods and Systems for Composing and Transmitting Content-Rich Communications,” Roberts et al., published on Oct. 18, 2001) describes methods, systems, and articles of manufacture that provide the ability for composing and transmitting a communication (such as an electronic mail message) using a content server within a communications network. The content associated with the communication is identified, typically by accessing it from storage or capturing it from peripheral devices. A location for the identified content is then determined within a layout for the body of the communication. The content is then streamed to a dynamic content server instead of being attached to the communication itself. When all of the content for the communication has been identified and streamed to the server, a minimal amount of information is transmitted to the intended recipient within the communication. This transmitted minimal amount of information includes an instruction set referencing the communication's content stored on the server.
Further to such methods for reducing email capacity, it is also known in the art how to track mail pieces. For example, U.S. Pat. No. 7,003,376 (“Method for tracking a mail piece,” Witmond et al., issued on Feb. 21, 2006) discloses a system and method that include capturing an image of the mail piece, associating a tracking number for the mail piece with the image, providing the mail piece and tracking number to a carrier, and utilizing information from the image to investigate a lack of delivery, if no delivery verification is received from the carrier within a certain time period. The system and method may also include extracting information from a portion of the image and presenting the extracted information to a carrier, receiving additional information related to the mail piece from the carrier, providing the mail piece, the additional information, and a tracking number for the mail piece to a carrier, inserting the mail piece into a mail stream, and then utilizing information from the image to investigate a lack of delivery if no delivery verification is received from the carrier within a certain time period.
Furthermore, WO 2006036042 (“Method and System for Providing Permanent Mail Service,” Ahn Jung Eun et al., published on Apr. 6, 2006), for example, discloses a method and system for storing mail permanently without restriction of storage space of mailbox. When a user makes a request to store certain mail permanently, a mail server transforms the requested mail data into permanent mail data with a predetermined format. The transformed mail data is transmitted to an external server that provides personal information storage space. The external server stores received permanent mail data on corresponding user area. If the user makes a request to read the permanent mail data, the mail server requests the requested permanent mail data from the external server, and the external server transmits the requested permanent mail data to the mail server, enabling users to read mails indicated as permanent mail regardless of the capacity of the mailbox.
It should be appreciated that traditional email systems are “pull” based, i.e., the MUA (email reader) polls the MDA (the mail server) to see if there is new mail, and if so downloads it to a mailbox in the user's home directory. Yet, mail messages have been pushed, that is, actively transferred from the origin to the destination MDA. In email systems that are “push” based, the pushing of messages pushing is extended, while messages are pushed also to the MUA (the email reader, or client). Push based email systems are adapted, for example, for devices that are “always on”, such as RIM's BlackBerry® (Research In Motion Ltd. Corp., Waterloo, Ontario, Canada) devices that are connected via a wireless network. RIM's BlackBerry service uses wireless MUAs which are the BlackBerry devices, and a BlackBerry Enterprise Server (BES), which is a gateway attached to a traditional e-mail system. The BES monitors the e-mail server, and upon detecting a new mail message for a BlackBerry user, it retrieves (pulls) a copy thereof and pushes it to the BlackBerry handheld device over the wireless network.
A push based email system is described, for example, in U.S. Pat. No. 5,436,960 (“Electronic Mail System with RF Communications to Mobile Processors and Method of Operation Thereof,” Campana Jr. et al., issued on Jul. 25, 1995), which discloses a system for transmitting originated information from one of a plurality of originating processors in an electronic mail system to at least one of a plurality of destination processors in the electronic mail system. The system includes a RF information transmission network for transmitting the originated information to at least one RF receiver which transfers the originated information to the at least one of the plurality of destination processors, at least one interface switch. The electronic mail system transmits other originated information within the electronic mail system through a telephone network.